home *** CD-ROM | disk | FTP | other *** search
- From: clamage@Eng.Sun.COM (Steve Clamage)
- Message-ID: <4dh93f$c3s@engnews1.Eng.Sun.COM>
- X-Original-Date: 16 Jan 1996 22:33:19 GMT
- Path: in2.uu.net!bounce-back
- Date: 17 Jan 96 00:50:13 GMT
- Approved: fjh@cs.mu.oz.au
- Newsgroups: comp.std.c++
- Subject: Re: operator T* amibiguities
- Organization: Sun Microsystems Inc.
- References: <r4ohs3kdek.fsf@erawan.cognex.com>
- Reply-To: clamage@Eng.Sun.COM
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMPxH3OEDnX0m9pzZAQHvsAF+NdVC0Da4JGO0CY2lEDlRka5dElMDXpnx
- cKNA329DEWZeothakkBkVeJAp5lXPeVR
- =K+tk
-
- In article fsf@erawan.cognex.com, Michael Cook <mcook@cognex.com> writes:
- >Does the standards committee consider this code ambiguous:
-
- > struct X;
- > struct Y
- > {
- > operator X*();
- > operator const X*() const;
- > };
- > void* f(Y y)
- > {
- > return y; //10
- > }
-
- >A couple compilers (different vendors) say it /is/ ambiguous, but I can't
- >see why.
-
- The ARM (and early versions of the C++ draft standard) said that any
- data pointer type could be converted implicitly to void*. Under that
- rule, the code is ambiguous.
-
- That rule also allows silent loss of the const qualifier, which is wrong.
- The rule was changed so that there is no implicit conversion to void* from
- a cv-qualified pointer. Under the new rule, the code is not ambiguous, and
- the conversion to X* would be selected.
-
- ---
- Steve Clamage, stephen.clamage@eng.sun.com
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-